IBIS Macromodel Task Group Meeting date: 03 December 2013 Members (asterisk for those attending): Agilent: * Fangyi Rao * Radek Biernacki Altera: * David Banas Julia Liu Hazlina Ramly Andrew Joy Consulting: Andy Joy ANSYS: Samuel Mertens * Dan Dvorscak * Curtis Clark Steve Pytel Luis Armenta Arrow Electronics: Ian Dodd Cadence Design Systems: Terry Jernberg * Ambrish Varma Feras Al-Hawari * Brad Brim Kumar Keshavan Ken Willis Cavium Networks: Johann Nittmann Celsionix: Kellee Crisafulli Cisco Systems: Ashwin Vasudevan Syed Huq Ericsson: Anders Ekholm IBM: Greg Edlund Intel: Michael Mirmak Maxim Integrated Products: Mahbubul Bari Hassan Rafat Ron Olisar Mentor Graphics: * John Angulo Zhen Mu * Arpad Muranyi Vladimir Dmitriev-Zdorov Micron Technology: * Randy Wolff Justin Butterfield NetLogic Microsystems: Ryan Couts Nokia-Siemens Networks: Eckhard Lenski QLogic Corp. James Zhou SiSoft: * Walter Katz * Todd Westerhoff Doug Burns * Mike LaBonte Snowbush IP: Marcus Van Ierssel ST Micro: Syed Sadeghi Teraspeed Consulting Group: Scott McMorrow * Bob Ross TI: Casey Morrison Alfred Chong Vitesse Semiconductor: Eric Sweetman Xilinx: Mustansir Fanaswalla Ray Anderson The meeting was led by Arpad Muranyi ------------------------------------------------------------------------ Opens: - Arpad: Reminder that we have two more meetings then a two week break. -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Walter produce new syntax examples using EMD-like format - Done ------------- New Discussion: Walter suggested moving some agenda items to a tabled items list at the bottom. IBIS EBD/EMD/interconnect direction: - Walter showed Package On-Die Interconnect: Decisions Made, Proposed Solutions - slide 3: - Walter: This shows what will be in .ibs and what will be in .ebd/EMD - We will not address optical - Brad: Are 3-D structures like interposers and stacked die? - Walter: Yes - Brad: Why not optical, when it is used an on-board interconnect? - Walter: That would be a good discussion - Arpad: Optical is very non-linear, it may not fit - slide 4: - Walter: IBISCHK does not flag duplicate signal names as an error - slide 5: - Walter: This proposes to identify power groups by signal name - [Pin Mapping] does it by pin name - Bob: [Pin Mapping] names are actually buses - slide 9: - Walter: EMD-like is only a bit more verbose than shorthand port notation - slide 10: - Walter: The [Pin Numbers] section is unnecessary - That is the main difference between BIRD 125 and EMD-like - slide 13: - Walter: Notation like .s2p just means it has 2 ports, not necessarily an s-param - A deficiency of BIRD 125 is not having names for models - slide 14: - Walter: This example includes just VDD, no grounds - slide 15: - Bob: This looks analogous to a subckt call, listed in order - slide 17: - Walter: This is like BIRD 125, but it doesn't do everything vendors want - This is a good approximation for many high speed packages - Brad: Should we use "net name" instead of "signal name"? - Walter: We can debate that - I treat things with the same signal name as shorted together - Bob: Does "Sig" mean I/O buffer or power? - Walter: The [Pin] list shows that pretty clearly - Some IBIS files repeat signal names though - Bob: We don't check this because in ECL POWER/GND can actually be a negative reference - slide 18: - Walter added "L=.5" to the syntax example line for Pin.5 - This satisfies a request from Michael Mirmak - slide 19: - Walter inserted "Port naming options" - John: On slide 13 is the example at the bottom an alternative syntax? - Walter: No it is just a shorthand notation - This does the same thing as BIRD 125 - Radek: What are the question marks for? - Walter changed the example to explain. - Radek: Is it for something not yet proposed? - Walter: It is proposed in both EMD and BIRD 125 - Ambrish: The question is about what "shorthand" means - Walter: It is just for this presentation, not a syntax proposal - Bob: The syntax might require instantiating multiple circuits for one line - Walter: That would mean denying Intel's request - John: On slide 8 is the purpose of [Die Supply Pad] to define nets for referring to SPICE models? - Walter: Yes - John: The circuits would have to obey the connectivity as defined here - It would be an error to connect to more than one signal group - Walter: Yes, that's the way it works - Walter: BIRD 125 must be extended to handle - Ambrish: BIRD 145 handles most of slide 19 - Walter: We need a description of what problem BIRD 145 solves - Ambrish: BIRD 145 does not require a circuit for sNp - Walter: It has and RDL example and one other - Arpad: It is BIRD 144 that handles sNp directly - Ambrish: Yes AR: Walter send update presentation to Mike for posting ------------- Next meeting: 10 December 2013 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives